NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c/54

Internet Message Format | 1996-08-06 | 6.4 KB

Path: mail2news.demon.co.uk!genesis.demon.co.uk
From: Lawrence Kirby <[e-mail]>
Newsgroups: comp.std.c
Subject: Re: Undefined result vs. int's holding undefined values.
Date: Tue, 09 Jan 96 02:37:54 GMT
Organization: none
Message-ID: <[e-mail]>
References: <4ck70b$[e-mail]> <4ckms5$[e-mail]> <4cmg0s$[e-mail]> <[e-mail]> <4cs460$[e-mail]>
Reply-To: [e-mail]
X-NNTP-Posting-Host: genesis.demon.co.uk
X-Newsreader: Demon Internet Simple News v1.27
X-Mail2News-Path: genesis.demon.co.uk

In article <4cs460$[e-mail]>
           [e-mail] "Daniel Wood" writes:

>[e-mail] (Thad Smith) wrote:
>>In article <4cmg0s$[e-mail]>,
>>[e-mail] (Paul Eggert) wrote:
>>>This reminds me of a similar bug I found a long time ago when porting
>>>the Modula-3 runtime, which contained code that acted something like this:
>>>
>>>      int sum_overflow (int x, int y) {
>>>              return (x + y < x) != (y < 0);
>>>      }
>>>
>>>The C Standard does not guarantee that the above function works,
>>>since integer overflow leads to undefined behavior,
>>>but when I found that the function did not work with whatever old version
>>>of GCC I was using at the time, I reported it as a bug to the GCC maintainers
>>>and got a fix from them in a few days.
>>>
>>>Regardless of what the C Standard says, it should be obvious that it's
>>>crucial to have integer overflow checking working properly in an
>>>application that needs it.
>>
>>I agree, but it is possible to rewrite the function so that it doesn't
>>invoke undefined behavior:
>>
>>  #include <limits.h>
>>  int sum_overflow (int x, int y) {
>>      return x > 0? (y > INT_MAX - x) : (y < INT_MIN - x);
>>  }
>>
>>Thad
>
>I totally understand what you are doing in the above but this would have to
>be the ultimate in a cheap out for a vendor.

Rubbish. A standard only works if all parties stick to it. A program which
overflows signed integer arithmetic is plain broken and no vendor has the
responsibility to support it, any more than they, for instance, have to
support arbitrary casting between ints and pointers. Historically there is
code that has relied on that but as time progresses it get fixed.

>SCO could claim that before
>ever looking at a test case containing a suspected compiler bug that every
>arithmetic calculation would have to first have a test similar to the above
>to protect against overflow/underflow.

What SCO claim in that case doesn't matter. Either the program does
invoke undefined behaviour according to the standard or it does not. There
are many ways a program can invoke undefined behavior, and many of those
not always trivial to prove or disprove in a particular program. You might
just as well say that a program would have to test against NULL every time
it dereferences a pointer. Your argument also applies to floating point
arithmetic.

> Does an appropriate "SAFE TEST" exist
>for multiple.  Has anyone actually seen a real production program where every
>calculation was protected against overflow/underflow.

In most instances the ranges of the variables concerned are known and hence
it can be guaranteed that a signed integer operation won't overflow. If it
does you have a bug in the program or are depending on behaviour which the
C language doesn't guarantee and which doesn't work on some systems for
good reasons.

>Shame on SCO for using such a cheap out.

The compiler I saw this on was icc which is the Intel Reference Compiler
(which SCO supply, but is controlled by Intel). The stock SCO compiler
probably satisfies your wishes. The Intel compiler is designed purely and
simply for speed and it does some very hairy optimisations. The bottom line
is that if it compiles strictly conforming code it is a conforming C
compiler and 100% correct. If Intel managed to squeeze extra speed out by
not supporting the 'normal' form of undefined behavour then full marks to
them - it would be silly to slow the generated code down to support illegal
source code. (I don't think anybody ever accused Intel of a 'cheap out'
on their compiler before!)

> There is no reason on an intel based
>platform not to be able to create an "IMPLEMENTATION DEFINED and consistant"
>behavior implementation instead of undefined behavior.

It is the C standard that makes the behaviour undefined, not the
implementation. If the behaviour you desire were so essential it would have
been incorporated into the standard. In fact the C standard defines this
sort of behaviour for unsigned types, so if you need it use those. I have
yet to encounter a program that really needs well defined signed integer
overflow behaviour and can't be done simply another way.

> Granted the standard
>doesn't require it but I have never seen a program with the kind of extra
>checking that seems to be required.

And even with well-defined integer overflow behaviour most programs would
fail/generate garbage results if overflow occurred, so it doesn't really
help.

>Integer overflow/wraparound producing some
>specific defined behavior is easily "doable" on all machine architectures I
>know of even if the results might differ on different machines.

If you can't get consistent results on different machines it is rather
pointless.

>Do any machines exist which actually explode when you add two number together
>such that the result would exceed MAXINT? :-)  Get pratical!

One possible behaviour is to generate an exception on integer
overflow and some archetectures can support this.

>I am particularly interested in the answer to my "safe multiply" question
>above.  It would be quite funny to find that there is actually no way to
>create, in a practical way, a safe c program that used multiple if the
>standard was followed to the letter of the law.

In the general case this is quite difficult in any language that
doesn't have multiple-precision support. There are various ways you could
tackle it e.g. one analogous to the sum example, or using floating point.
It may be easier if the test can fail on values close to INT_MIN and INT_MAX,
or the code assumes that INT_MIN is -INT_MAX (such an assumption may help
portability by, for example, only allowing the ranges guaranteed by the
standard).

--
-----------------------------------------
Lawrence Kirby | [e-mail]
Wilts, England | [e-mail]
-----------------------------------------